Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9608/000042_owner-urn-ietf _Tue Aug 27 18:36:27 1996.msg

Internet Message Format | 1997-02-19 | 8KB

Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id SAA26121 for urn-ietf-out; Tue, 27 Aug 1996 18:36:27 -0400
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id SAA26116 for <[e-mail]>; Tue, 27 Aug 1996 18:36:19 -0400
Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA10165  (mail destined for [e-mail]); Tue, 27 Aug 96 18:36:06 -0400
Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id QAA21885; Tue, 27 Aug 1996 16:35:59 -0600 (MDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 27 Aug 1996 16:41:37 -0600
To: [e-mail] (Leslie Daigle), [e-mail]
From: Ron Daniel <[e-mail]>
Subject: Re: Need Input -- was Re: [URN] Concerns
Sender: [e-mail]
Precedence: bulk
Reply-To: Ron Daniel <[e-mail]>
Errors-To: [e-mail]

Thus spoke Leslie Daigle (at least at 04:33 PM 8/27/96 -0400)
...
>Let me try to summarize how I read the two sides of
>the point, and draw out of it one issue that I would like to hear responses
>on -- both affirming and dissenting, so that we can see what the overall
>feeling is.
>
>    . We can build a URN system that requires some syntactic structuring
>      of _all_ components of a URN, with a view to providing more
>      rigourous (how many u's do we use in that word in Canada?!)
>      maintenance structures, resolution operations, etc.
>
>    . We can build a URN (resolution) system that relies on federating
>      heterogeneous name spaces -- both existing and future.  In this
>      case, the primordial need is to build a system that can accommodate
>      the needs of a broad spectrum of namespaces with widely divergent
>      aims and goals.  The goal is to provide some set of standardized
>      mechanisms for handling URNs of all namespaces, while minimizing
>      the requirements placed on the structure of the name.
[...]
>The real issue on which there needs to be traffic is which of the two
>paths we are going to follow here -- or creative suggestions for an
>alternate position.

Well, I don't know how creative this is, but there is a middle ground
to consider. Let me point it out for compleness, then say why I still
like the second of your two items.

Your first point talks about the structuring of "all" components of a
name. I take that to mean that the developer of a namespace could write
some expression that would not only check that the syntax of the namespace
is being followed, but could yank out pieces of the URN and
put them into some canonical order for resolution. This was the gist
of Lewis' proposal. The problem with this is that the designer's knowledge
stops at the boundries of any "opaque string" in the name. Therefore,
the ability to delegate resolution also stops at that point, because we
can't detect components in the opaque string. However, lots of publishers
may want to put structure into their opaque strings and use that
structure in the resolution process for delegation. With the first model,
they don't get to, which is why I find it pretty much unacceptable.

As a middle ground between the two positions, we could have one where
the designer writes an expression that validates the URN and puts its
components into the canonical order up to the opaque string. Then,
when the resolution process has gotten us to a server that corresponds
with that opaque string boundary, we can get a new expression to
check the syntax and put it into the canonical order. (This model should
also allow recursive opaque strings).

I could live with this middle ground if it were the consensus of the
group that it was the correct model, but I still like it less than the
other position that Leslie mentioned, for at least three reasons:
  1) I think that the model where we can do a rewrite at any stage of
     the resolution process gives us enough power to get ourselves out
     of unforseeable jams down the line. I know that I am not smart
     enough to see the future clearly. I would rather approach it with
     a big toolkit than a small one.
  2) I think that the resolution system du jour should have no impact
     whatsoever on the allowed structure of names. What we do to make
     names easier to resolve for today's URN resolution system stands
     an excellent chance of making things more difficult to resolve
     for tomorrow's resolution system. We also stand a chance of not being
     able to handle some namespace because we didn't put the right
     wrench into our toolkit.
  3) I think that it will be more difficult to construct the expressions
     that check syntax, reorder the components, eat components off of the
     canonical order, etc. than it will be to construct the regular
     expression alternatives.  This difficulty stems from 3 areas:
     a) The conceptual model, which I think is much more difficult to
        understand than rewrites of the URN.
     b) The need to manage multiple inputs and outputs. Lewis' proposal
        has programs, rules, URNs, domain names, and the canonical string.
        Programs are what convert the URN into the canonical string. Rules
        are what eat components from the front of the canonical string and
        give the next domain name to look at. In addition to that task,
        the rules leave the canonical string shorter for the next rule.
        In contrast, the model in the NAPTR draft has URNs, domain names,
        and regexps. The next domain name to query can either be supplied
        directly (the replacement field) or can be obtained by a rewrite
        of the original domain name.
     c) The bit about the canonical string is important. Using the
        canonical string puts us into the situation where the input to
        a rule is the output of another. This is something that makes
        rewrite rules confusing, because you can't understand a rule
        without knowing how all preceding rules have affected the input
        string. Also crucial is that if someone upstream in the resolution
        process changes their rule, and changes the handling of a delimiter,
        all of a sudden your rules can be broken. In contrast, the rewrite
        rules in the NAPTR proposal can be understood in isolation, because
        they are applied to the URN and have a single output - a domain name.

        I should note that the canonical string offers a powerful advantage
        in addition to the disadvantages I have just mentioned. Since
        the canonical string shrinks at each stage of the resolution
        process, we have a gurantee of termination. The NAPTR stuff can
        detect cycles, but has no way of avoiding a long slow walk through
        a large "funhouse",  if someone can construct such a space without
        being detected. I believe that this possibility is more remote
        than the one of upstream changes.


All my humble opinion of course,  :-)

Ron Daniel Jr.                       email: [e-mail]
Advanced Computing Lab               voice: [phone]
MS B287                                fax: [phone]
Los Alamos National Laboratory        http://www.acl.lanl.gov/~rdaniel/
Los Alamos, NM, USA  87545       tautology:"Conformity is very popular"